Ambiguity: Whether to use dhcproto's RelayMessage or build our own codec.
Choice: Implemented custom byte-level encode/decode for RELAY_FORW/RELAY_REPL messages.
Rationale: dhcproto v0.14 RelayMessage has all-private fields with getters only — no constructor or setters. Cannot build one programmatically. The wire format is simple (34-byte header + TLV options) making a custom codec straightforward and dependency-light.
Ambiguity: How deep relay nesting can go.
Choice: Recursive decapsulate() — if the extracted relay-message is itself RELAY_REPL, recurse.
Rationale: RFC 3315 allows up to 32 hops. Recursion handles arbitrary depth cleanly. Stack overflow is not a concern at 32 max depth.
Spec said: peer-address is the client's source address.
Implemented: If peer_addr is IPv4, sets peer-address to Ipv6Addr::UNSPECIFIED.
Why: DHCPv6 relay messages always use IPv6 addresses. An IPv4 peer in a DHCPv6 context is a configuration error, but mapping to :: is safer than panicking.
Alternatives: (A) Fork dhcproto and add RelayMessage constructor/setters; (B) Build our own codec on the wire format.
Chose B: 100 lines of straightforward code vs maintaining a fork of an external crate. If dhcproto adds proper constructors in a future version, we can migrate.
Issue #5 will add Interface-ID (18) and Remote-ID (37) options to the relay-forward message. The current codec only handles relay-message option (9). Option insertion/extraction APIs will need to be added or the codec extended to support generic option TLV handling in relay messages.